Debugging of multi-threaded hardware simulation processes is generally carried out by suspending all threads of the hardware simulation process before beginning debugging operations. Most debuggers rely upon the operating system to assist in debugging the hardware simulation process, and most operating systems (e.g., Windows, Linux, etc.) require the suspension of all threads. Once all the threads of the multi-threaded hardware simulation process are suspended, a user may step through or otherwise examine simulation results from the simulation of the hardware model to locate and fix bugs in the hardware model.
Since conventional debugging systems debug multi-threaded hardware simulation processes when all threads are suspended, they provide users limited debugging functionality for multi-threaded hardware simulation processes which rely upon the suspended threads to communicate with other applications (i.e., using interprocess communication). For example, where the state of the simulated platform model depends upon information in another application, the conventional debugger may return an incomplete or incorrect picture of the simulated hardware state for debugging purposes.
Additionally, the ability of conventional debugging systems to debug embedded software (e.g., applications run on the simulated hardware component) is also limited when all threads of the hardware simulator are suspended. Debugging of embedded software generally requires an embedded software debugger to access the state of the underlying simulated platform. Accordingly, by suspending interprocess communication threads of the hardware simulation, the interprocess communication channels used by the embedded software debugger to access the state of the simulated platform are severed. As such, conventional debugging systems provide embedded software debuggers with limited access to the state of the simulated platform, thereby resulting in incomplete and potentially inaccurate information for debugging of the embedded software.